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Unicast-—Prefix-Based IPv4 Multicast Addresses 

Abstract 
This specification defines an extension to the multicast addressing 
architecture of the IP Version 4 protocol. The extension presented 
in this document allows for unicast-prefix-—based assignment of 
multicast addresses. By delegating multicast addresses at the same 
time as unicast prefixes, network operators will be able to identify 
their multicast addresses without needing to run an inter-domain 
allocation protocol. 
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1. Introduction 


RFC 3180 [RFC3180] defines an allocation mechanism (called "GLOP") in 
233/8 whereby an Autonomous System (AS) number is embedded in the 
middle 16 bits of an IPv4 multicast address, resulting in 256 
multicast addresses per AS. Advantages of this mechanism include the 
ability to get multicast address space without an inter-domain 
multicast address allocation protocol, and the ease of determining 
the AS that was assigned the address for debugging and auditing 
purposes. 


Some disadvantages of GLOP include: 


o RFC 4893 [RFC4893] expands the size of an AS number to 4 bytes, 
and GLOP cannot work with 4-byte AS numbers. 


o When an AS covers multiple sites or organizations, administration 
of the multicast address space within an AS must be handled by 
other mechanisms, such as manual administrative effort or the 
Multicast Address Dynamic Client Allocation Protocol (MADCAP) 
[RFC2730]. 


o During debugging, identifying the AS does not immediately identify 
the correct organization when an AS covers multiple organizations. 


o Only 256 addresses are automatically available per AS, and 
obtaining any more requires administrative effort. 


More recently, a mechanism [RFC3306] has been developed for IPv6 that 
provides a multicast range to every IPv6 subnet, which is at a much 
finer granularity than an AS. As a result, the first three 
disadvantages above are avoided (and the last disadvantage does not 
apply to IPv6é due to the extended size of the address space). 
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Another advantage of providing multicast space to a subnet, rather 
than just to an entire AS, is that multicast address assignments 
within the range need only be coordinated within the subnet. 


This document specifies a mechanism similar to [RFC3306], whereby a 
range of global IPv4 multicast address space is provided to each 
organization that has unicast address space. A resulting advantage 
over GLOP is that the mechanisms in IPv4 and IPv6 become more 
similar. 


This document does not obsolete or update RFC 3180, as the mechanism 
described in RFC 3180 is still required for organizations with prefix 
allocations more specific than /24. Organizations using RFC 3180 
allocations may continue to do so. In fact, it is conceivable that 
an organization might use both RFC 3180 allocations and the 
allocation method described in this document. 


2. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 

3. Address Space 
A multicast address with the prefix 234/8 indicates that the address 


is a Unicast-Based Multicast (UBM) address. The remaining 24 bits 
are used as follows: 


Bits: | 0 thru 7 | 8 thru N | N+1 thru 31 
4+------- 4-------------------- 4----------------------------- + 

Value: | 234 | Unicast Prefix | Group ID 
4+------- 4-------------------- 4----------------------------- + 


For organizations with a /24 or shorter prefix, the unicast prefix of 
the organization is appended to the common /8. Any remaining bits 
may be assigned by any mechanism the organization wishes. 


For example, an organization that has a /16 prefix assigned might 
choose to assign multicast addresses manually from the /24 multicast 
prefix derived from the above method. Alternatively, the 
organization might choose to delegate the use of multicast addresses 
to individual subnets that have a /24 or shorter unicast prefix, or 
it might choose some other method. 


Organizations with a prefix length longer than 24 do not receive any 


multicast address space from this mechanism; in such cases, another 
mechanism must be used. 
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Compared to GLOP, an AS will receive more address space via this 
mechanism if it has more than a /16 for unicast space. An AS will 
receive less address space than it does from GLOP if it has less than 
a /16. 


The organization that is assigned a UBM address can be determined by 
taking the multicast address, shifting it left by 8 bits, and 
identifying who has been assigned the address space covering the 
resulting unicast address. 


The embedded unicast prefix MUST be a global unicast prefix (i.e., no 
loopback, multicast, link-local, or private-use IP address space). 

In addition, since global unicast addresses are not permanently 
assigned, UBM addresses MUST NOT be hard-coded in applications. 


4. Examples 


The following are a few examples of the structure of unicast-prefix-— 
based multicast addresses. 


o Consider an organization that has been assigned the global unicast 
address space 192.0.2.0/24. This means that organization can use 
the global multicast address 234.192.0.2 without coordinating with 
any other entity. Someone who sees this multicast address and 
wants to find who is using it can mentally shift the address left 
by 8 bits to get 192.0.2.0, and can then look up who has been 
assigned unicast address space that includes that address. 


o Consider an organization that has been assigned a larger address 
space, x.y.0.0/16. This organization can use the global multicast 
address space 234.x.y.0/24 without coordinating with any other 
entity, and can assign addresses within this space by any 
mechanism the organization wishes. Someone who sees a multicast 
address (say) 234.x.y.10 and wants to find who is using it can 
mentally shift the address left by 8 bits to get x.y.10.0, and can 
then look up who has been assigned unicast address space that 
includes that address. 


5. Security Considerations 


The same well-known intra-domain security techniques can be applied 
as with GLOP. Furthermore, when dynamic allocation is used within a 
prefix, the approach described here may have the effect of reduced 
exposure to denial-of-service attacks, since the topological area 
within which nodes compete for addresses within the same prefix is 
reduced from an entire AS to only within an individual organization 
or an even smaller area. 
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6. 


slg 


rA 


IANA Considerations 


IANA has assigned a /8 in the global IPv4 multicast address space for 
this purpose. 
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